Shareware Super Platinum 8

home *** CD-ROM | disk | FTP | other *** search

/ Shareware Super Platinum 8 / Shareware Super Platinum 8.iso / mac / PROGTOOL / CX201E.ZIP;1 / CX.DOC < prev next >

Wrap

Text File | 1994-03-02 | 36.3 KB | 868 lines

€€€ €€€ €€€ € € € € € €€ € € € €€€ € € € € € € € € € €€€ € € €€€ € €€€ €€€ Copyright (c) 1987-1994 Four Lakes Computing Hello! -------------------------------------------------------------------------- This manual and the included test programs should give you a good idea of how to use Cx. If you have ANY questions or want to talk to a knowledgeable person about Cx, or data compression in general, PLEASE call or send a note to: * Compuserve 70662,2501 * US Telephone (608) 256-3382 * US Address Four Lakes Computing 1135 Williamson #4 Madison, WI 53703 All questions welcome. No sales pressure. Promise! Many applications (like backup programs) which must have complete data integrity are currently using Cx. Cx is used with MS-DOS, Windows, OS/2, Macintosh, and even some UNIX applications. Applications which use Cx are written in C, C++, Pascal, Assembly, BASIC, Visual BASIC and others. Cx is used by very small companies as well as very large corporations. In short, you don't have to worry about support, porting, bugs, or royalties when you use Cx. The purchasers of Cx have found Cx to be the highest performance data compression library that is commercially available (customer comments are included below). In addition, Cx may be purchased with very portable source code to further protect your investment. Cx 2.01 is priced at $145 ($295 with ANSI C and 80x86 assembly source). Cx 2.01 is royalty free. A one time purchase fee grants you the right to use Cx 2.01 in any or all of your applications. Using this manual -------------------------------------------------------------------------- This manual has the following sections: * Comments from Cx Users * -> * Evaluation Package Differences (IMPORTANT!) * * Included Files * * What's New * * Upgrading from Cx 1.* * * Benchmarks * * Using Cx * * The Cx Programming Interface * * Programming, Compiler, Environment Notes * * Where is the Object Code? / The Object Code Manager * * The CXF Source Code * * Cx 2.01 Ordering Information * Comments from Cx Users -------------------------------------------------------------------------- The following quotes pertain to Cx versions 1.* and 2.01, and ALL quotes are used with the permission of the authors (Cx 2.01 was released in February 1994). * My initial tests show great advantage over my current technique! - 29-Aug-92 Norm Patriquin, CIS: 70254,643 * For your information, I currently use another well known compression library for my backup product and you appear to be 30% faster than their routines. Their compression library has been detuned and does not operate as fast as their stand alone programs. - 01-Sep-92 Norm Patriquin, CIS: 70254,643 * Well, we have made all the code changes in MegaBack [tm], and your compression routines work great! Our experience with method 1 is a 23% [speed] improvement over the compression done by the other popular compression library and it even reduced the size of the compressed data! - 11-Sep-92 Norm Patriquin, CIS: 70254,643 * Your product is MUCH BETTER than your CX.DOC advertises! - 19-Apr-93 E. Nicholas Cupery, author of the Farba Utilities (tm) * Yours is a fine product, and it's great to deal with someone so *responsive*. - 19-Apr-93 E. Nicholas Cupery, author of the Farba Utilities (tm) * ... because ___ Inc and I are so closely linked I don't publicly endorse products, however, I would like to personally congratulate you on a fine product. Again, thanks for a fine product. - 13-May-93 Unnamed * BOTTOM LINE: It looks to me like your new CX v2.01 is a significant improvement. - 2-Feb-94 E. Nicholas Cupery, author of the Farba Utilities (tm) * I currently use the Cx compression routines in all my products and recommend them highly. I have tried several other compression libraries and yours are clearly the fastest and best! - 17-Feb-94 Norm Patriquin, CIS: 70254,643 Evaluation Package Differences -------------------------------------------------------------------------- The differences between the evaluation package and the purchaseable package are entirely contained in the object code. In all other respects the evaluation and purchaseable packages are identical. !! The included program TEST.EXE may be used for determining the EXACT !! speed and compression levels of the purchaseable object and source code. The evaluation package contains different object code from that which may be purchased. The interface, however, is IDENTICAL. The differences in the evaluation package object code are listed below: * The object code included in the evaluation package runs MUCH slower than the object code that may be purchased. * All methods in the evaluation object code compress to the same level (namely CX_METHODC). * The evaluation object code will not run indefinitely. * The evaluation object code has a slightly different size than the object code that may be purchased. * The evaluation object code may only be used for evaluating the interface to Cx. NO other usage or distribution rights are granted. Included Files -------------------------------------------------------------------------- TEST.EXE - Cx 2.01 Test/Benchmark program CX.DOC - this document LICENSE.DOC - license for Cx 2.01 (read before purchasing) ORDER.DOC - ordering information VENDOR.DOC - information for vendors and distributors of Cx COMMENTS.DOC - comments from Cx users FILE_ID.DIZ - BBS compatible description of Cx SOURCE.DOC - Included with source code purchase only. CX.H - C/C++ interface to Cx CX.PAS - Pascal interface to Cx CX.BAS - BASIC interface to Cx CXEQU.ASM - 80x86 assembly interface to Cx VBCX.BAS - Visual BASIC interface to CX CXSUB.DOC - documentation for CXSUB routines CXSUB.C - CXSUB C/C++ routines CXSUB.H - CXSUB C/C++ interface CXSUB.PAS - CXSUB Pascal routines and interface VBCXSUB.BAS - CXSUB Visual BASIC routines and interface CXF.C - C/C++ example program CXF.BAS - BASIC example program CXF.PAS - Pascal example program VBCXF.MAK - Visual BASIC example project file VBCXF.FRM - Visual BASIC example form BINIO.DOC - documentation for BINIO.DLL BINIO.DLL - Windows 3.*+ DLL for binary file I/O BINIO.LIB - Windows 3.*+ import library for BINIO.DLL VBBINIO.BAS - Visual BASIC interface to BINIO.DLL MCXF.BAT - MS-DOS batch file to compile test programs MCXF.CMD - OS/2 batch file to compile test programs OCM.EXE - Object Code Manager OCM.DAT - Cx 2.01 Object Code WINIO.OBJ - Object file that allows C based Windows programs to emulate console programs. This data is provided courtesy of Microsoft Systems Journal, Andrew Schulman and Dave Maxey, and is available on Compuserve in the Microsoft Languages Forum (GO MSL) as files S13103.ZIP and S13155.ZIP. *.DOC - Documentation files VB*.* - Visual BASIC files What's New -------------------------------------------------------------------------- Cx 2.01 features: * 100% compatibility with Cx 1.* compressed data and CRCs. * A new super fast compression method (60% + faster than Cx 1.*). * A new super fast decompression method (60%+ faster than Cx 1.*). * Generally faster and smaller compression than Cx 1.* methods. * Faster CRC computation. * Better object code organization for a potential RAM reduction. Upgrading from Cx 1.* -------------------------------------------------------------------------- The programming interface to Cx has remained the same, although the values of two constants have changed (CX_C_MINTEMP and CX_D_MINTEMP). Two new compression methods have been added, CX_METHODC and CX_METHODD. These allow for faster compression or decompression. Using the Object Code Manager, it is now possible to tailor the Cx object code for reduced memory requirements. Using the Object Code Manager, you can include Cx 1.* decompression compatibility. That's it! Benchmarks -------------------------------------------------------------------------- The included program TEST.EXE may be used for comparing Cx with other compression products. TEST.EXE uses the CXSUB routines (source code is included here), and is compiled using Microsoft C 8.00. These benchmarks where produced on a 386 40 MHZ PC, using TEST.EXE. The headings indicate: C.TST - 1MB of C source files AP.TST - 1MB of Associated Press wire stories (in English) EXE.TST - 1MB of executable programs SIZE - relative size CTIME - relative compression time DTIME - relative decompression time All measurements are relative, with 1.00* indicating the best performance. C.TST AP.TST EXE.TST SIZE CTIME DTIME SIZE CTIME DTIME SIZE CTIME DTIME --------------------------------------------------------------- PKZIP 2.04g 1.00*| 2.07 | 1.27 1.00*| 2.07 | 1.00* 1.00*| 1.63 | 1.18 PKZIP 1.1 1.14 | 3.18 | 1.27 1.13 | 2.57 | 1.00* 1.08 | 2.33 | 1.00* lharc 1.13c 1.25 | 9.16 | 5.73 1.22 | 3.43 | 4.74 1.08 | 3.30 | 6.76 lha 2.13 1.12 | 5.59 | 2.58 1.12 | 3.68 | 2.37 1.04 | 2.60 | 2.64 arj 2.30 1.01 | 4.18 | 2.31 1.01 | 3.37 | 2.02 1.01 | 2.59 | 2.42 pak 2.51 1.18 | 4.59 | 3.08 1.15 | 3.01 | 2.30 1.08 | 2.60 | 2.80 arc 6.02 1.98 | 2.32 | 5.04 1.55 | 1.75 | 3.65 1.41 | 1.58 | 3.93 Cx 2.01/c 1.40 | 1.00*| 1.15 1.42 | 1.00*| 1.19 1.11 | 1.00*| 1.02 Cx 2.01/d 1.19 | 2.47 | 1.00* 1.22 | 2.10 | 1.05 1.05 | 2.14 | 1.00* Cx 2.01/1 1.19 | 2.30 | 1.54 1.20 | 1.85 | 1.53 1.05 | 1.76 | 1.40 Cx 2.01/2 1.13 | 3.06 | 4.73 1.13 | 2.34 | 3.84 1.04 | 2.29 | 3.71 Cx 2.01/3 1.10 | 3.65 | 6.38 1.10 | 2.78 | 4.95 1.04 | 2.99 | 6.93 PKZIP (tm) is a trademark of PKWARE, Inc. Note that some of the providers of the listed programs also provide compression libraries, and these libraries may have very different performance characteristics. For direct comparisons between libraries, it is suggested that you obtain free evaluation packages from these providers. Some of the highlights of this data: * Cx 2.01/c is at least 60% faster when compressing than any other algorithm. Typically 2 to 3 times faster. * Cx 2.01/d is always within 5% of the fastest decompressor, and provides very good compression. * Cx 2.01/1 performs much better than lharc 1.13c (perhaps the most popular compressor ever made) in all measurements, usually be a wide margin. * Cx 2.01/2 and Cx 2.01/3 compress within 13% of the best compressors. Using Cx -------------------------------------------------------------------------- Cx is a data compression programming library. As such, it can not do anything on it's own. An application which uses Cx must be created. Cx was designed so it would not imply anything about the application that is using it, or the language the application was written in. Application writers have a lot of versatility in the ways they can use Cx. Cx does not know anything about files, archive formats or serial communications. Cx knows about memory buffers. A memory buffer is simply an area of memory. For Cx to compress or decompress data, the calling application needs to tell Cx about three memory buffers: * The source of input data. * The destination of output data. * An area of memory that Cx may use for temporary storage. The application also needs to tell Cx how big these memory buffers are so that Cx will not access any memory outside of this area. With the three buffers and the three associated sizes, a total of 6 parameters are needed to the Cx compression and decompression routines. The only other parameter is to the Cx compression routine. This parameter tells Cx what method of compression to use. This gives your application the ability to balance compression size, compression speed and decompression speed. As mentioned earlier, Cx does not know anything about files. It is not much harder, however, to write a routine that compresses a file using Cx than to write a routine to simply copy a file. Routines to compress one file to another are provided in the included source code files. The hardest part about using Cx is correctly setting up the parameters to be passed. The programming interface found below is fairly terse, but provides precise information about using Cx. The Cx Programming Interface -------------------------------------------------------------------------- This programming interface does not imply any language or environment. See the section 'Programming, Compiler, Environment Notes' for more information, or see the following Cx interface files: CX.H CX.PAS CX.BAS VBCX.BAS CXASM.EQU When interfacing to a language which can not use one of these interface files, consult one of them for the exact values of constants. It is suggested that you create a similar interface file for the language you are using. It is very important to use the constants included in the interface files, as they may change in future versions of Cx. Data Types ------------------------------------------------------------------- CXINT - A 16 bit unsigned integer. CXINTSIZE - The size of CXINT (2 bytes). CXBUFF - A 32 bit pointer to a buffer. CXCALL - 32 bit (far) Pascal calling convention Constants ------------------------------------------------------------------- CX_ERR_INVALID - Error code returned by Cx routines. CX_ERR_METHOD - ... CX_ERR_BUFFSIZE - ... CX_ERR_TEMPSIZE - ... CX_METHODC - Identifies compression method C. CX_METHODD - Identifies compression method D. CX_METHOD1 - Identifies compression method 1. CX_METHOD2 - Identifies compression method 2. CX_METHOD3 - Identifies compression method 3. CX_MAX_BUFFER - The maximum buffer size that may be compressed. CX_SLOP - The amount the Cx routines may overrun compressed buffers. CX_C_MINTEMP - The minimum amount of temporary memory the Cx compression routine needs. CX_C_MAXTEMP - The maximum amount of temporary memory the Cx compression routine can use. CX_D_MINTEMP - The minimum amount of temporary memory the Cx decompression routine needs. Note that there is no CX_D_MAXTEMP because the Cx decompression routine does not need and will not use more than CX_D_MINTEMP. Function CX_COMPRESS(method, obuff, osize, ibuff, isize, tbuff, tsize) ---------------------------------------------------------------------- PARAMETERS: method Method of data compression to use (one of the CX_METHOD* constants). obuff Output buffer where compressed data is to be placed. osize Size of obuff. osize must be within the range [0..CX_MAX_BUFFER]. CX_COMPRESS must have read/write access to bytes [0..osize+CX_SLOP-1] in obuff. ibuff Input buffer containing data to compress. The contents of ibuff are not modified by CX_COMPRESS. isize Bytes of data in ibuff to compress. isize must be within the range [0..CX_MAX_BUFFER]. tbuff A buffer that will be used by Cx for temporary storage. tsize Size of tbuff. Cx needs at least CX_C_MINTEMP bytes of temporary storage while compressing, but can make use of up to CX_C_MAXTEMP bytes. The more temporary storage provided to Cx, the greater the potential for compression. tsize must be within the range [CX_C_MINTEMP..CX_C_MAXTEMP]. RETURN VALUE: CX_ERR_METHOD The compression method requested is invalid or unsupported in the called version of CX_COMPRESS. CX_ERR_BUFFSIZE isize or osize is not within the range [0..CX_MAX_BUFFER]. CX_ERR_TEMPSIZE size is not within the range [CX_C_MINTEMP..CX_C_MAXTEMP]. isize (if the value in passed parameter isize is returned) The data in ibuff was not compressable or would not fit into obuff. In this case, no assumptions about the contents of obuff should be made. else (if none of the above, the typical return) The data in ibuff was successfully compressed to obuff. The return value is the number of compressed bytes placed in obuff. Function CX_DECOMPRESS(obuff, osize, ibuff, isize, tbuff, tsize) ---------------------------------------------------------------------- PARAMETERS: obuff Output buffer where decompressed data is to be placed. osize Size of obuff. Usually, osize will be the number of bytes that where compressed into ibuff, but osize may be smaller, allowing for partial decompression of a buffer. CX_DECOMPRESS must have write access to bytes [0..osize] in obuff. ibuff Input buffer containing data compressed with Cx. The contents of ibuff are not modified by CX_DECOMPRESS. isize Size of ibuff. CX_DECOMPRESS recognizes the end of the compressed data in ibuff by a special 'End of Data' symbol, NOT by consulting isize. isize is used to prevent CX_DECOMPRESS from accessing memory it should not when the data in ibuff is invalid or corrupt. isize must be within the range [0..CX_MAX_BUFFER]. CX_DECOMPRESS must have read access to bytes [0..isize+CX_SLOP-1] in ibuff. tbuff A buffer that will be used by Cx for temporary storage. tsize Size of tbuff. tsize must be at least CX_D_MINTEMP. CX_DECOMPRESS does not need (and will not use or access) more than CX_D_MINTEMP bytes of temporary storage. RETURN VALUE: CX_ERR_METHOD The data in ibuff is invalid, corrupt, or was compressed with a method not supported in the called version of CX_DECOMPRESS. CX_ERR_INVALID The data in ibuff is invalid or corrupt, and can not be completely decompressed. In this case, CX_DECOMPRESS may be called with different values of osize to find the largest amount of data that can be decompressed without an error. CX_ERR_BUFFSIZE isize is not within the range [0..CX_MAX_BUFFER]. CX_ERR_TEMPSIZE tsize is smaller than CX_D_MINTEMP. else (if none of the above, the typical return) The data in ibuff was successfully decompressed into obuff. The return value is the number of decompressed bytes placed into obuff. Function CX_CRC(buff, bytes) -------------------------------------------------------------- PARAMETERS: buff Buffer to compute 16 bit Cyclical Redundancy Check (CRC) on. bytes The number of bytes in buff. RETURN VALUE: 16 bit CRC Programming, Compiler, Environment Notes --------------------------------------------------------------------- The following is a collection of notes that provide more specific information on a variety of subjects: * Choosing a Compression Method * * What is CX_SLOP? * * Memory Considerations / Low Memory Situations * * Re-entrancy * * Handling Uncompressable Data * * Detecting Errors / Using a CRC * * Interfacing to 80x86 Object Code * * Using Unsigned Integers. * * Building a Turbo/Borland Pascal TPU * Choosing a Compression Method ----------------------------------------------------------------- When you call CX_COMPRESS, you need to indicate what method of compression to use. This allows you to balance size and speed. The following compression methods may be specified: CX_METHODC - fastest compression CX_METHODD - fastest decompression CX_METHOD1 - general purpose (fastest, but largest) CX_METHOD2 - general purpose (faster, medium size) CX_METHOD3 - general purpose (slowest, smallest) This is a general guideline only. You should try different methods with your application to determine what works best. What is CX_SLOP? ------------------------------------------------------------------ CX_SLOP is needed for performance reasons. Cx performs faster when it is allowed to slightly overrun buffers that will (or do) contain compressed data. For example: ibuff = allocate (k) bytes obuff = allocate (k+CX_SLOP) bytes <- a little bigger than k CX_COMPRESS(CX_METHOD1, obuff, k, ibuff, k, ...) ibuff = allocate(k+CX_SLOP) bytes <- a little bigger than k obuff = allocate(k) bytes CX_DECOMPRESS(obuff, k, ibuff, k, ...) Note that CX_SLOP is not included as part of the passed buffer size: CX_COMPRESS(CX_METHOD1, obuff, k+CX_SLOP, ibuff, k, ...) <- WRONG! CX_DECOMPRESS(obuff, k, ibuff, k+CX_SLOP, ...) <- WRONG! In these examples, CX_COMPRESS may write up to CX_SLOP bytes past the end of obuff (obuff[k] to obuff[k+CX_SLOP-1]), and CX_DECOMPRESS may read up to CX_SLOP bytes past the end of ibuff (ibuff[k] to ibuff[k+CX_SLOP-1]). CX_DECOMPRESS will NOT modify the contents of the slop area in any way, and this area does not need to be initialized in any way. CX_DECOMPRESS may simply read this area of memory. When using Cx with an operating system that does not provide memory protection (like MS-DOS), it is not necessary to explicitly make room for the slop area when calling CX_DECOMPRESS. Explicitly defining a slop area, however, will make your code portable to environments that have memory protection. Memory Considerations / Low Memory Situations ----------------------------------------------------------------- It is best to present large buffers to CX_COMPRESS for maximum compression. At most, this could amount to three 64k buffers (approximate), or 192k. If this is not acceptable, the input and output buffers can be made smaller, and/or the temporary storage size reduced. As an extreme example, 8k buffers could be used for input and output with temporary storage of 18k (CX_C_MINTEMP), for a total of 34k. The only way to find an acceptable solution is to experiment with buffer sizes. It may also be helpful to pass an output buffer smaller than the input buffer when compressing if you are sure of a particular level of compression. If, for example, you know that compression is always going to be about 50%, obuff can be less than the size of ibuff when compressing. When decompressing, there are not many alternatives because decompression is based on the original buffer sizes. Note, however, the temporary storage required when decompressing is less (7k). You may be able to reduce memory requirements by choosing a smaller version of the object code. Re-entrancy ------------------------------------------------------------------ All Cx functions are re-entrant. The Cx functions do not require any special programming considerations when used in multi-tasking or multi-threaded environments. Handling Uncompressable Data ------------------------------------------------------------------ The included source code demonstrates a good way to handle uncompressable data. Unless you can completely guarantee that your application will not encounter uncompressable data, it is a good idea to plan for it. The example programs handle uncompressable data as follows: Stored with each compressed (or uncompressable) buffer are 2 16 bit integers. The first integer indicates the size of the original buffer and the second integer indicates the size of the stored buffer. If these two integers are identical, the application determines that the stored buffer is not compressed. Detecting Errors / Using a CRC ------------------------------------------------------------------ It is not always possible to detect invalid compressed data when running CX_DECOMPRESS. Invalid compressed data meaning data which is not the exact output of the compression algorithm. The main reasons you might end up with invalid data are: Application or System Error (bugs, ...) Incorrect Application or System Termination (power failure, ...) Undetected Hardware/Storage Failure (highly unlikely) Computers are very good at detecting errors in RAM and on disk media. It is unlikely that you will have bad RAM or disks, without the system informing you. Many people are very familiar with floppy disk failures. In other words, if you end up with invalid compressed data because of a hardware or storage failure, the system will probably inform you. Not being able to detect invalid compressed data is not a weakness in CX_DECOMPRESS, but is a consequence of a good compression algorithm. A good algorithm will not 'waste' any code space on error conditions. In practice, however, most algorithms will be able to detect some errors. When CX_DECOMPRESS detects an error, it will return with the value CX_ERR_INVALID. A good way to detect invalid compressed data is with the use of CRC's. A CRC (Cyclical Redundancy Check) basically maps an arbitrarily large piece of information into a small integer (typically 16 or 32 bits). This mapping is (of course) not reversible (otherwise it would be great for data compression!). There are an infinite number of data buffers that have the same CRC. In practice, however, it is highly unlikely that two buffers will have the same CRC (1 in 65535 with a 16 bit CRC). It is even more unlikely for a 'slightly' corrupt buffer to have the same CRC as a valid buffer. To use a CRC to check for invalid data, you store a CRC along with the compressed data. Later, when you want to decompress, you can compare the stored CRC with the stored data to ensure the stored data is valid. Typically, a CRC is computed on the original data. This provides a lot of confidence that decompressed data is identical to the original. Testing has shown, however, that a CRC computed on the compressed data is better able to detect errors. In addition, this has the added advantage of being quicker to compute (as compressed buffers will typically be smaller than the original buffer). The included source code demonstrates how CX_CRC may be used to help detect errors. When an error is detected, however, you do not have a lot of options other than informing the operator (as with a floppy disk failure). Interfacing to 80x86 Object Code -------------------------------------------------------------------- This section will be of interest primarily to assembly language programmers, and users of 80x86 compilers that have not yet been tested. The following notes apply to all 80x86 object code, but are of particular use when interfacing to CX.OBJ and CX.LIB. * Depending upon the object code used (see section Object Code Manager), the following segment will be used: CODE SEGMENT 'CODE' <- 'Normal' segment definition CODE SEGMENT <- 'Simplified' segment definition This is the ONLY segment definition used in Cx 80x86 object code. The environment used must allow read as well as execute privilege to this segment. * All buffers passed must be 32 bit pointers using the 80x86 segmented memory mechanism. These are typically called 'far' pointers. When interfacing Cx with a 32 bit application, a translation typically needs to be made on the pointers being passed. * A far call should be placed to all Cx routines. * The pascal calling convention is used. This convention is common for inter-language programming. As an example, CX_CRC looks like: CX_CRC(buff, bytes) push bp mov bp,sp ... here bp[8..11] contains the 32 bit (far) pointer to buff here bp[6..7] contains the number of bytes ... mov sp,bp pop bp retf 6 <- Far return, 4 bytes for buff, 2 for bytes } * All 'normal' flags and the following registers may be modified by the Cx routines: AX, BX, CX, DX, ES * The AX register contains the return value for all Cx routines. * All Cx routines are re-entrant. * All Cx routines use less than 256 bytes of stack space. Using Unsigned Integers -------------------------------------------------------------------- The Cx routines accept as parameters, and return, 16 bit unsigned integers. A 16 bit unsigned integer can hold any value between (and including) 0 and 65535. Many languages have direct support for unsigned integers, and need no special attention, but others, like BASIC, do not. For these languages, it is suggested that you use long (32 bit) integers in your application, and convert to and from 16 bit signed integers immediately before and after they are needed. For example: k = CX_COMPRESS(..., ltoi(osize), ... lk = itol(k) Where the conversion routines are: itol(i) - if i < 0 then itol = 65536+i else itol = i ltoi(l) - if l > 32767 then ltoi = l-65536 else ltoi = l Building a Turbo/Borland Pascal TPU -------------------------------------------------------------------- To build CX.TPU, you must compile CX.PAS (tpc cx). CX.PAS uses CX.OBJ. Use the Object Code Manager to extract the version of CX.OBJ you need. Some versions of Turbo/Borland Pascal require a simplified code segment, and others do not. The Object Code Manager will ask you if you want a simplified code segment. If you are in doubt, try it both ways. You will get a compilation error if you are using the wrong version of CX.OBJ. Where is the Object Code? / The Object Code Manager -------------------------------------------------------------------------- There are many different 'builds' of object code that are included with Cx 2.01. The reasons for this are listed below: * Compilers interface to slightly different types of .OBJ and .LIB files. * Some applications will need all of the Cx routines, while others will only need some. * Some applications need the ability to decompress Cx 1.* data, while others do not. All of the Cx 2.01 object code is stored in the file OCM.DAT. Object code may be extracted from OCM.DAT using the included MS-DOS program OCM.EXE. Simply run OCM.EXE from a directory containing OCM.DAT. When you run OCM, you will be prompted with a series of questions about the type of object code you want extracted. The names and types of object code that may be extracted when running OCM.EXE are listed below: CX.OBJ - linkable in MS-DOS, Windows and OS/2 CX.LIB - linkable in MS-DOS, Windows and OS/2 CXWIN.DLL - Windows 3.*+ DLL CXWIN.LIB - Windows 3.*+ import library CXOS2.DLL - OS/2 1.*+ DLL CXOS2.LIB - OS/2 1.*+ import library It is important to remember that any DLL's you distribute may conflict with other previously installed Cx DLL's. For this reason, you should ensure that you access the DLL's you distribute (i.e. keep them in your applications directory). The CXF Source Code ------------------------------------------------------------------------- The CXF source code may be used to create an example program which uses the included object code. The CXF source code relies heavily on the CXSUB family of functions. Source code for these functions is provided here (see CXSUB.DOC). To compile CXF for many compilers, run: MCXF.BAT - MS-DOS MCXF.CMD - OS/2 To compile CXF for Visual Basic, use the project: VBCXF.MAK Visual Basic users will also want to examine BINIO.DOC. Cx 2.01 Ordering Information ------------------------------------------------------------------------- To purchase Cx 2.01, fill out this ordering form. You will receive: * All Cx 2.01 commercial object code. * The right to distribute Cx 2.01 object code (refer to LICENSE.DOC for specific rights) royalty free. * ANSI C and 80x86 assembly language source for Cx 2.01 (if purchased). * Printed documentation and technical support from the author of Cx. Prices: $145 USD Cx 2.01 $295 USD Cx 2.01 + source $45 USD Cx 1.* upgrade to Cx 2.01 $195 USD Cx 1.* upgrade to Cx 2.01 + source $45 USD Cx 1.* + source upgrade to Cx 2.01 $95 USD Cx 1.* + source upgrade to Cx 2.01 + source Wisconsin residents add 5% sales tax $5 USD for non-USA shipping $10 USD for next day delivery (USA only) $3 USD for second day delivery (USA only) Make Payment To: Four Lakes Computing Payment Methods: US Check, US Money Order, US Dollars, American Express International Money Order. Send Payment To: Four Lakes Computing 1135 Williamson #4 Madison, WI 53703 USA Address: __________________________________________________ __________________________________________________ __________________________________________________ __________________________________________________ Other contacts (phone, Compuserve, Internet, ... ) __________________________________________________ __________________________________________________ __________________________________________________ __________________________________________________ PO Number: ________________________ Disk: ___ 5 1/4 ___ 3 1/2 If you have any questions, contact the address above or: US Phone: 608-256-3382 Compuserve ID: 70662,2501